Hi @ruihe774. Thanks for your PR.

I'm waiting for a ostreedev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

What I will say, was there actually a bug or defect found here, etc.?

Not appeared. But it is easy to produce one. You can set the SUID bit of a program using libostree (e.g. ostree itself). In a program that gains privilege by SUID, getuid() returns the user that invokes the program, and geteuid() returns 0.

/ok-to-test

No one should be including libostree in a setuid binary. (Really there should be no setuid binaries at all, but that's another thing)

Yes. However, processes can drop privileges temporarily using seteuid() as well. In this case, getuid() returns 0 and geteuid() returns a unprivileged uid.

Yes. However, processes can drop privileges temporarily using seteuid() as well. In this case, getuid() returns 0 and geteuid() returns a unprivileged uid.

Yeah, though that kind of thing I personally consider a bad idea because most modern codebases are multithreaded, and changing uid affects all threads, which can have surprising effects. Basically if you do this type of thing you should fork off a dedicated helper process which runs always as that uid from the start - and that process shouldn't be doing anything related to ostree in general.

/override continuous-integration/jenkins/pr-merge

@cgwalters: Overrode contexts on behalf of cgwalters: continuous-integration/jenkins/pr-merge

and changing uid affects all threads

This is implemented by libc (e.g. NPTL). If you use raw syscall (sounds tricky), changing uid affects only current thread.

If you use raw syscall, changing uid affects only current thread.

Yes, but doing raw syscalls like that last I heard from the glibc developers often means you cannot invoke any later APIs from glibc, which becomes a giant pain in the butt. I'm not sure if there's a better reference but (searches for a minute) yeah see this comment for example.